1. Field of the Invention
This invention is directed to managing certain operations between an Open Systems Interconnection (OSI) manager and agent running on a Common Management Information Protocol (CMIP) platform. More particularly, the invention relates to establishing a Notification Forwarding Discriminator (NFD) at an agent. The manager can turn on this NFD, and leave it on as a monitor until the manager turns it off.
2. Description of Related Art
In OSI standards, managed resources are represented by managed objects, or more particularly managed object instances. Management applications interact with managed objects which in turn interact with the resources they represent. A managed object can report the status of the resource it represents in two ways: In direct response to an operation requesting status information or by emitting an unsolicited message, called a notification, which indicates the resource's status has changed. These options are not mutually exclusive--a managed object may support both methods.
Management applications, which monitor the status of physical resources, need to know that the status information it has is current or that the monitoring mechanism is not working. The two most common approaches to meeting this need using OSI management techniques have substantial problems. The first approach is for a management application to poll all of the managed objects that represent the resources of interest by sending them request operations requesting status information. With this approach, a management application knows when the monitoring mechanism is not working. The application either does not receive a response to a request it has sent (the response "times out"), or the application has returned an error indicating a communication failure. For example, an application monitoring the topology of an APPN communication network could periodically send request operations to managed objects requesting status information. If the application does not receive a response from a particular managed object, it knows that it lacks current status information on that resource and can mark that resource as unreliable.
However, there are two drawbacks to polling. First, a lot of processing time and network traffic are required. Second, as the number of polled managed objects increases, the status becomes less current, as the polling interval must be increased to maintain acceptable network communication performance.
In the second approach, the management application subscribes to the notifications emitted by managed objects. Notifications are peculiar messages because they are not directed to a particular destination. OSI management standards have defined a special managed object, called an Event Forwarding Discriminator (EFD), that receives all notifications emitted by all managed objects on the same system. A management application can set two attributes of an EFD ("discriminatorConstruct" and "destination") to control what types of notifications should be forwarded to it via messages called event reports. Once a management application has set up EFDs on each of the systems it wishes to monitor, it merely waits for an unsolicited event report to arrive. This approach eliminates the network traffic associated with polling, and reduces the processing overhead in the management application. However, it increases processing overhead in the systems where EFDs determine if notifications should be forwarded.
Further, there is a second problem with the EFD approach in that a management application does not know when this monitoring mechanism is no longer working. When a session between a management application and a system with an EFD is lost, there is no way for the application to know that it will not receive any event reports from that EFD, unless it polls the EFDs to make sure that the sessions are still active. While this is not as expensive as polling the managed objects that represent the resources of interest, it becomes less practical as the size of a network increases. In addition, the event reports are unsolicited, so there are no open, or pending, operations as viewed by the management application. An EFD will try to send an event report, but the report will not be delivered. Meanwhile, the management application waits for event reports, unaware that the monitoring mechanism is no longer working. For example, an application monitoring the topology of an APPN network could create EFDs that listen for notifications that indicate a status change and forward them as event reports to the application. The status will be as current as possible until communication is lost. If a transmission group becomes inactive while the communication is lost, the managed object representing the transmission group emits a notification, an EFD processes notification and attempts to forward it as an event report, but the event report cannot be delivered. The management application, completely unaware that there is a problem, still indicates that the transmission group is active.
The OSI management infrastructure hides the details of which sessions are used for communication between managed systems from management applications. Even if the management infrastructure were to inform an application that a session was lost, an application would not know if it was affected by the loss of that session.
Queuing event reports for delivery when communication is re-established does not satisfy the requirement that an application knows when the monitoring is not working.